In the environment of computing, software products very often include the capability to accommodate third party “plug-ins”. Third party plug-ins include, for example, storage drivers, networking drivers, and various other modules made by a third party (i.e., someone other than the party that developed the original software product). As a result, the end product used by customers is frequently comprised of the originally provided software product, e.g., an application, and any number of third party plug-ins. Should a customer experience a problem with the end product, the customer typically reports the problem to the party that developed the original software product. The source of the problem, however, may be one the many third party plug-ins, not the original software product. Thus, it is critical for software developers to be able to accurately determine the actual source of the problem.
As is known in the art, a crash or system crash refers to a situation in which a computer program such as, for example, an operating system or a software application ceases to function properly. When such a crash occurs, a purple screen of death (PSOD) containing a stack trace or listing of threads just prior to the crash is commonly generated. In some cases, depending upon the type operating system or computer platform, the display of the stack trace may have another color or may be referred to using a different name or acronym. Customers may provide the PSOD to the party that developed the original software product and expect a timely and accurate response informing the customer of the source of the crash. It is obvious that there are significant business ramifications associated with incorrectly blaming a party for causing a crash, or for being unable to accurately provide the customer with the source of the crash in a timely manner.
In conventional approaches, after a crash, the support team for the original software product is now faced with the pressure of determining the source of the crash. In the conventional art, in order to determine the source of the crash, the support team typically takes the entire stack trace received from the customer and then manually examines it and compares the entire stack trace to a database of previously received entire stack traces (often such databases are not even available) whose problems were previously determined. That is, in conventional approaches, the support team hopes find some similarity between the current stack trace and a prior stack trace whose problem was previously determined. In so doing, the support team hopes to be able to state, with some level of confidence, that similar stack traces have the same problem source. Unfortunately, such conventional approaches are error prone, tedious, time-consuming, and often fail to yield accurate information about the source of the crash. More specifically, similar stack traces often have very different sources for their corresponding crashes. Thus, conventional approaches for manually comparing stack traces are not acceptable for determining the source of a software crash.